to fix issue #79897

Please add relevant information why the old commit needs to be reverted to the commit message.

Please add relevant information why the old commit needs to be reverted to the commit message.

updated

But why do we need to revert the commit 1da74ef, what kind of issue it is causing now?

But why do we need to revert the commit 1da74ef, what kind of issue it is causing now?

Pls check this bug #79897.
It causes build error when DPP disabled and HOSTAPD enabled, because of incomplete wrap.
So why do we need this commit 1da74ef? From my side it is conflict to review comments in the original DPP PR #73707.
@krish2718 any comments?

But wouldn't the original issue then be present what the 1da74ef is fixing if we revert it?

But wouldn't the original issue then be present what the 1da74ef is fixing if we revert it?

If hostap disables DPP (by disabling CONFIG_WIFI_NM_WPA_SUPPLICANT_DPP, which is zephyr only way to disable DPP),
L2 DPP code will be still there and can be tested, no build error, which is from original review comments request.
Only hostap will return fail when DPP L2 api is called, which won't be trouble.
So I don't see what 1da74ef is trying to fix. Could you pls explain it in detail?

But wouldn't the original issue then be present what the 1da74ef is fixing if we revert it?

If hostap disables DPP (by disabling CONFIG_WIFI_NM_WPA_SUPPLICANT_DPP, which is zephyr only way to disable DPP), L2 DPP code will be still there and can be tested, no build error, which is from original review comments request. Only hostap will return fail when DPP L2 api is called, which won't be trouble. So I don't see what 1da74ef is trying to fix. Could you pls explain it in detail?

Please see #79897 (comment) just including the header file is enough to get this error, but for some reason not seen with upstream.

@jukkar @krish2718 updated fix. thanks for clarification.

Not sure about twister policies in upstream, but should we add these combinations to avoid such issues?

Not sure about twister policies in upstream, but should we add these combinations to avoid such issues?

That would be a good idea to add various config combinations to tests, not sure if tests/net/wifi/wifi_nm is a good place for those. Perhaps separate directory next to it to compile test various config combinations or enable-all type config.

Perhaps separate directory next to it to compile test various config combinations or enable-all type config

Just saw a PR merged with build_all that builds all drivers, we can have something similar for WPA supp?

Just saw a PR merged with build_all that builds all drivers, we can have something similar for WPA supp?

Yeah we could, I can prepare a PR for that.